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(54) Title: RECLAIMING MEMORY FROM DELETED APPLICATIONS 



(57) Abstract 

The invention provides a method for removing code (appli- 
cations and data) from read-only memory, and compacting the re- 
maining code in memory either as an application is deleted or when 
there is not sufficient room to hold a new application. One or more 
"spare" memory segments are reserved for use during compaction. 
Where the code for removal shares a memory segment with other 
code that is not be removed, the other code is copied to a spare 
memory segment, and then swapped back to its original location. 
The code can then be compacted to remove the "holes" left by the 
erased code. 
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RECLAIMING MEMORY FROM DELETED APPLICATIONS 

Field of the Invention 

The present invention is directed to the area of memory management 
in computer systems with segmented memory space, such as embedded devices, 
and specifically provides a system for safely reclaiming memory and 
realigning the remaining applications contiguously in non-volatile, 
erasable " flash" -type memory. 

Background of the Invention 

This application is particularly useful in embedded systems with 
memory constraints, but is applicable in any environment in which 
applications may be removed from a machine and it is desirable to compact 
the remaining applications stored in memory, in order to provide the 
maximum amount of contiguous free space for new applications. 

In embedded systems, total system memory may be in the order of 1 to 
4 megabytes. Ideally, half of the system memory should be devoted to 
read-only memory (ROM) , for storing applications and data which persist 
between sessions. Applications can be loaded, in sequential order, until 
the memory limits of the system are reached. 

For the purposes of this invention, reference will be made to 
"flash" type memory. Technically, flash is a form of ROM in that it is 
non-volatile, but it is also erasable, generally in 64K byte blocks, 
according to current technology. 

Particularly in the rapidly developing area of wireless 
communications, it may be necessary or desirable to delete existing 
applications in a device before a new application can be downloaded, 
either to free adequate memory to accommodate the new application ( s) or to 
avoid incompatibility with newer versions of an application. 

Summary of the Invention 



The present invention is directed to a system for safely removing 
applications from ROM, and then compacting the ROM to remove any "holes" 
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left by application removal. This ensures that the maximum amount of 
contiguous free memory is made available for new application download. 

In one embodiment, the present invention is directed to an 
5 improvement in a device's non-volatile memory. This flash memory is 

characterized by having multiple memory segments adapted to receive and 
store application code and data. Preferably at least one memory segment 
is reserved for use during memory compaction, which is adapted to receive 
code and/or data copied from another memory segment of the read-only 
10 memory. A mechanism for correcting pointers within the code to reference 

the new memory location of the code and/or data copied from another 
memory segment of the read-only memory is also provided. 

According to another aspect, the present invention provides a method 
15 for removing a defined body of code from a read-only memory with multiple 

memory segments and at least one memory segment reserved for use during 
compaction. In the method, if it is determined that the defined body of 
code overlaps into a memory segment shared with other code, the other code 
is copied into a memory segment reserved for use during compaction, the 

2 0 memory segment reserved for compaction is swapped with the memory segment 

shared with other code, and the memory segment containing a portion of the 
defined body of code is erased. 

Brief Description of the Drawings 

25 

Figure 1, which comprises Figures 1A through ID, schematically 
illustrates code removal and compaction in the read-only-memory (ROM) of a 
constrained memory device, according to the invention; 

30 Figure 2 is a flow diagram illustrating the steps for code removal, 

according to the invention; and 

Figure 3 is a flow diagram illustrating the steps for memory 
compaction following code removal, according to a preferred embodiment of 

3 5 the invention. 

Detailed Description of the Preferred Embodiments 



40 



As schematically illustrated in Figure 1 (consisting of Figures 1A 
through ID) , a ROM 2 in a constrained memory device, such as a cellular 
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telephone, could typically comprise 32 64K memory segment blocks, 
generally designated by 4, to total 2 megabytes of flash memory in the 
device . 

5 In the implementation of the invention for the preferred embodiment, 

the applications in the ROM are allocated from low memory to high memory. 

As shown in Figures 1A and IB, an application 6, shown in 
cross-hatch shading, spans two and a half memory segment blocks 4 in ROM 
10 2 - Code or data 8, shown in diagonal striping, from a contiguously stored 

application shares one memory segment with the first part of the 
application 6. 

Only entire blocks of memory can be erased in the flash memory used 
15 in these devices, as discussed above. Therefore, if the user wants to 

erase the application at 6, the device's memory manager will have to save 
the code or data 8 from the contiguously stored application and then 
restore it to this location. 

20 This is accomplished by retaining one or more spare memory blocks to 

use for swapping out blocks of stored code or data to retain in the 
device. In the preferred embodiment, the manager of the "flash" memory 
simply reserves the highest block (s) for the compaction process. In the 
example shown in Figure 1, the memory manager copies the code or data 8 

25 up into a spare block 10 (Figure IB) . Only the code/data from the block 

being deleted is copied; the top of the spare block is left empty. The 
spare block containing the copied code 10 is then "swapped" with the 
original memory block at 12 (Figure 1C) , and the memory blocks containing 
the remaining code/data of the application 6 can then be safely erased 

30 (Figure ID) . This swapping may be done in one of two ways: if a memory 

management unit (MMU) supporting "virtual" memory regions is available, 
the MMU mapping is changed so that the "new" block is using the address 
previously used by the block being deleted. The block being deleted is 
erased and its memory mapping is changed to the address being used 

3 5 previously by the spare block. If a MMU is not available, the contents of 

the "spare" block is copied on top of the original block, after it has 
been erased. 



The steps for this process are set out in the flow diagram of Figure 
40 2. When the user desires to delete an application from memory, the 
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device 1 s memory manager locates the start and end points in ROM of the 
application (block 20) to determine whether both are located on a memory 
segment boundary (blocks 22, 24) . If this is the case, it is safe for the 
memory manager to simply erase all memory segment blocks containing the 
5 application (block 28) and proceed to compaction which is shown in Figure 

3 . 

Continuing with Figure 2, if the memory manager determines that an 
end point of the application is inside a memory segment block (block 22 or 

10 24) , it next determines whether the application is sharing a memory 

segment block at this point with other code (block 26) . The "flash 
manager" keeps track of start and end addresses of each application and 
also knows the addresses of each memory block, so it is a simple 
calculation to determine where the application/data resides relative to 

15 the start/end of the memory blocks and other applications. 

If no other application code/data is located, it is safe to delete 
the original application (block 28) and proceed to compacting the ROM. 

20 If the memory manager determines that data or code from another 

application is stored in the same block with a portion of the original 
application for deletion (block 26) , this code or data is copied into a 
spare memory segment block (block 28) without any of the original 
application code (i.e., the spare memory segment block is partially 

25 blank) . 

The copy to the spare memory segment block is made in such a way 
that the device can recover if the device is powered off in the midst of a 
memory deletion/compaction operation. In the preferred embodiment, flags 
3 0 and markers are used to indicate the state of the application during the 

loading, deleting and compacting functions (block 30) . 

The code/data from the other application in the spare memory segment 
block is then swapped back to the bottom of the original application to be 
35 deleted (block 34) . The flags and markers added to indicate that a 

transfer is underway are reset (block 36) and the memory segment blocks 
containing the remainder of the original application are erased (block 
38) . 
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Once the application has been removed, its memory must be reclaimed 
by compacting or "sliding" the applications above it down into the empty 
space. This leaves the maximum amount of contiguous free space at the top 
of the ROM for loading new applications. 

According to a preferred embodiment of the invention, compaction 
follows the same principles as for deleting an application, that is, spare 
memory segment blocks are used for transferring the content of partially 
filled memory segment blocks, and this process is illustrated in Figure 3. 

Once the application has been unloaded, the memory should be 
compacted in order to remove any "holes". This provides the maximum 
contiguous free memory for downloading new applications. A preferred 
method for performing compaction, utilizing the principles of the present 
invention, is illustrated in Figure 3. 

Following the application unload, the memory manager scans the 
memory to determine if there are any memory blocks populated with data or 
code above the memory blocks freed by unloading the application - that is, 
if unloading the application has left an empty "hole" in the recorded 
memory (block 40) . If not, then the unloaded application was at the top 
of the recorded memory, and compaction is not required. 

If there is recorded data/code above the freed memory, the memory 
manager determines whether a part or whole empty memory block is at the 
bottom of the freed memory (block 42) . 

If the freed memory is in whole memory blocks, compaction is 
performed simply, by copy the data blocks down the memory sequentially to 
the next empty memory block (block 44) , and adjusting the flags/markers 
for the new location of each block of data or code (block 46) . 

Where there is only a part memory available, the memory manager 
copies data/code from the data block to fill the part memory block (block 
48) and adjusts the flags/markers for the copied code (block 50) . 

In the same manner as discussed above in relation to Figure 2, the 
remaining data/code from the data block is copied to a spare memory block 
(block 52) and the flags/markers adjusted for the location of this 
code/data (block 54) . This spare memory block is swapped to the free 
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memory contiguous the already compacted data (block 56) , and the 
flags/markers of the data/code in the swapped block adjusted (block 58) . 

This process is performed recursively until all data has been 
compacted (block 40) . 

Although the invention has been described in association with 
preferred embodiments, it will be understood that it is applicable to 
other platforms and memory arrangements by employing modifications obvious 
to the person skilled in the art. 

In summary there is described a method for removing code 
(applications and data) from read-only memory, and compacting the 
remaining code in memory either as an application is deleted or when there 
is not sufficient room to hold a new application. One or more "spare" 
memory segments are reserved for use during compaction. Where the code 
for removal shares a memory segment with other code that is not to be 
removed, the other code is copied to a spare memory segment, and then 
swapped back to its original location. The code can then be compacted to 
remove the "holes" left by the erased code. 
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CLAIMS 

1. In a computing environment, a non-volatile memory having multiple 

memory segments adapted to receive and store application code and data, 
comprising : 

at least one memory segment being reserved for use during memory 
compaction and adapted to receive only code and/or data copied from 
another memory segment of the non-volatile memory; and 

a mechanism for correcting pointers/markers to reference a new 
memory location of the code and/or data copied from another memory 
segment of the non- volatile memory. 

15 2. A computing environment, according to claim 1, wherein the multiple 

memory segments are adapted to receive data for storage from a low end to 
a high end and wherein said at least one memory segment is reserved at the 
high end. 

20 3. A method for removing a defined body of code from a non-volatile 

memory having multiple memory segments, at least one memory segment being 
reserved for use during compaction, comprising: 

scanning the defined body of code for overlap into a memory segment 

2 5 shared with other code; 

copying the other code into a memory segment reserved for use during 
compaction; 

3 0 swapping the other code into a memory segment reserved for use 

during compaction ; 

erasing any memory segment containing a portion of the defined body 
of code . 

35 

4. A method, according to claim 3 wherein the step of swapping the 

memory segment reserved for compaction with the memory segment shared with 
other code, in a system having virtual memory regions and the memory 
segment shared with other code is at a first address, comprising mapping 
40 the memory segment reserved for compaction to the first address. 
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10 



5. A method, according to claim 3, wherein the step of swapping the 
memory segment reserved for compaction with the memory segment shared with 
other code comprises: 

erasing the memory segment shared with other code; and 

copying the memory segment reserved for compaction onto the erased 
memory segment . 

6. A computer- readable memory for storing the instructions for use in 
the execution in a computer of any one of the methods of claims 3 through 
5 . 

7. A computer program product comprising a computer usable medium 

15 having computer readable program code means embodied therein for causing a 

computer to remove a defined body of code from non-volatile memory having 
multiple memory segments of which at least one memory segment is reserved 
for use during compaction, the computer readable program code means in 
said computer program product comprising: 

20 

computer readable program code means for causing the computer to 
scan the defined body of code for overlap into a memory segment shared 
with other code; 

2 5 computer readable program code means for causing the computer to 

copy the other code into a memory segment reserved for use during 
compaction; 

computer readable program code means for causing the computer to 

3 0 swap the other code into a memory segment reserved for use during 

compaction; and 



35 



computer readable program code means for causing the computer to 
erase any memory segment containing a portion of the defined body of code. 
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